dri-devel November 2010

dri-devel@lists.freedesktop.org

74 participants
347 discussions

[PATCH 1/2] drm/radeon/kms: add support for clock/data path routers
by Alex Deucher 08 Nov '10

08 Nov '10

This is a follow on to: 26b5bc986423cf3887e09188cb662ed651c5374d (drm/radeon/kms: add support for router objects) That patch added support for systems that use a mux to control the ddc line routing between the connectors. This patch adds support for systems that use a mux to control the encoder clock and data path routing to the connectors. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=31339 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_atombios.c | 26 +++++++++++++----- drivers/gpu/drm/radeon/radeon_connectors.c | 4 +- drivers/gpu/drm/radeon/radeon_display.c | 18 +++++++----- drivers/gpu/drm/radeon/radeon_encoders.c | 8 +++++ drivers/gpu/drm/radeon/radeon_i2c.c | 41 ++++++++++++++++++++++----- drivers/gpu/drm/radeon/radeon_mode.h | 17 ++++++++--- 6 files changed, 85 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index ca33baf..07e3afb 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -526,7 +526,8 @@ bool radeon_get_atom_connector_info_from_object_table(struct drm_device *dev) if (crev < 2) return false; - router.valid = false; + router.ddc_valid = false; + router.cd_valid = false; obj_header = (ATOM_OBJECT_HEADER *) (ctx->bios + data_offset); path_obj = (ATOM_DISPLAY_OBJECT_PATH_TABLE *) @@ -647,7 +648,8 @@ bool radeon_get_atom_connector_info_from_object_table(struct drm_device *dev) usDeviceTag)); } else if (grph_obj_type == GRAPH_OBJECT_TYPE_ROUTER) { - router.valid = false; + router.ddc_valid = false; + router.cd_valid = false; for (k = 0; k < router_obj->ucNumberOfObjects; k++) { u16 router_obj_id = le16_to_cpu(router_obj->asObjects[j].usObjectID); if (le16_to_cpu(path->usGraphicObjIds[j]) == router_obj_id) { @@ -657,6 +659,7 @@ bool radeon_get_atom_connector_info_from_object_table(struct drm_device *dev) ATOM_I2C_RECORD *i2c_record; ATOM_I2C_ID_CONFIG_ACCESS *i2c_config; ATOM_ROUTER_DDC_PATH_SELECT_RECORD *ddc_path; + ATOM_ROUTER_DATA_CLOCK_PATH_SELECT_RECORD *cd_path; ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT *router_src_dst_table = (ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT *) (ctx->bios + data_offset + @@ -690,10 +693,18 @@ bool radeon_get_atom_connector_info_from_object_table(struct drm_device *dev) case ATOM_ROUTER_DDC_PATH_SELECT_RECORD_TYPE: ddc_path = (ATOM_ROUTER_DDC_PATH_SELECT_RECORD *) record; - router.valid = true; - router.mux_type = ddc_path->ucMuxType; - router.mux_control_pin = ddc_path->ucMuxControlPin; - router.mux_state = ddc_path->ucMuxState[enum_id]; + router.ddc_valid = true; + router.ddc_mux_type = ddc_path->ucMuxType; + router.ddc_mux_control_pin = ddc_path->ucMuxControlPin; + router.ddc_mux_state = ddc_path->ucMuxState[enum_id]; + break; + case ATOM_ROUTER_DATA_CLOCK_PATH_SELECT_RECORD_TYPE: + cd_path = (ATOM_ROUTER_DATA_CLOCK_PATH_SELECT_RECORD *) + record; + router.cd_valid = true; + router.cd_mux_type = cd_path->ucMuxType; + router.cd_mux_control_pin = cd_path->ucMuxControlPin; + router.cd_mux_state = cd_path->ucMuxState[enum_id]; break; } record = (ATOM_COMMON_RECORD_HEADER *) @@ -860,7 +871,8 @@ bool radeon_get_atom_connector_info_from_supported_devices_table(struct size_t bc_size = sizeof(*bios_connectors) * ATOM_MAX_SUPPORTED_DEVICE; struct radeon_router router; - router.valid = false; + router.ddc_valid = false; + router.cd_valid = false; bios_connectors = kzalloc(bc_size, GFP_KERNEL); if (!bios_connectors) diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 4dac4b0..60f283c 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -1116,7 +1116,7 @@ radeon_add_atom_connector(struct drm_device *dev, radeon_connector->shared_ddc = true; shared_ddc = true; } - if (radeon_connector->router_bus && router->valid && + if (radeon_connector->router_bus && router->ddc_valid && (radeon_connector->router.router_id == router->router_id)) { radeon_connector->shared_ddc = false; shared_ddc = false; @@ -1136,7 +1136,7 @@ radeon_add_atom_connector(struct drm_device *dev, radeon_connector->connector_object_id = connector_object_id; radeon_connector->hpd = *hpd; radeon_connector->router = *router; - if (router->valid) { + if (router->ddc_valid || router->cd_valid) { radeon_connector->router_bus = radeon_i2c_lookup(rdev, &router->i2c_info); if (!radeon_connector->router_bus) goto failed; diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1b2de67..2697801 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -317,10 +317,14 @@ static void radeon_print_display_setup(struct drm_device *dev) radeon_connector->ddc_bus->rec.en_data_reg, radeon_connector->ddc_bus->rec.y_clk_reg, radeon_connector->ddc_bus->rec.y_data_reg); - if (radeon_connector->router_bus) + if (radeon_connector->router.ddc_valid) DRM_INFO(" DDC Router 0x%x/0x%x\n", - radeon_connector->router.mux_control_pin, - radeon_connector->router.mux_state); + radeon_connector->router.ddc_mux_control_pin, + radeon_connector->router.ddc_mux_state); + if (radeon_connector->router.cd_valid) + DRM_INFO(" Clock/Data Router 0x%x/0x%x\n", + radeon_connector->router.cd_mux_control_pin, + radeon_connector->router.cd_mux_state); } else { if (connector->connector_type == DRM_MODE_CONNECTOR_VGA || connector->connector_type == DRM_MODE_CONNECTOR_DVII || @@ -400,8 +404,8 @@ int radeon_ddc_get_modes(struct radeon_connector *radeon_connector) int ret = 0; /* on hw with routers, select right port */ - if (radeon_connector->router.valid) - radeon_router_select_port(radeon_connector); + if (radeon_connector->router.ddc_valid) + radeon_router_select_ddc_port(radeon_connector); if ((radeon_connector->base.connector_type == DRM_MODE_CONNECTOR_DisplayPort) || (radeon_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP)) { @@ -434,8 +438,8 @@ static int radeon_ddc_dump(struct drm_connector *connector) int ret = 0; /* on hw with routers, select right port */ - if (radeon_connector->router.valid) - radeon_router_select_port(radeon_connector); + if (radeon_connector->router.ddc_valid) + radeon_router_select_ddc_port(radeon_connector); if (!radeon_connector->ddc_bus) return -1; diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index b8c6847..8feb6dd 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -1702,6 +1702,7 @@ radeon_atom_dac_detect(struct drm_encoder *encoder, struct drm_connector *connec static void radeon_atom_encoder_prepare(struct drm_encoder *encoder) { struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder); + struct drm_connector *connector = radeon_get_connector_for_encoder(encoder); if (radeon_encoder->active_device & (ATOM_DEVICE_DFP_SUPPORT | ATOM_DEVICE_LCD_SUPPORT)) { @@ -1713,6 +1714,13 @@ static void radeon_atom_encoder_prepare(struct drm_encoder *encoder) radeon_atom_output_lock(encoder, true); radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF); + /* select the clock/data port if it uses a router */ + if (connector) { + struct radeon_connector *radeon_connector = to_radeon_connector(connector); + if (radeon_connector->router.cd_valid) + radeon_router_select_cd_port(radeon_connector); + } + /* this is needed for the pll/ss setup to work correctly in some cases */ atombios_set_encoder_crtc_source(encoder); } diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c b/drivers/gpu/drm/radeon/radeon_i2c.c index 6a13ee3..24b8a8b 100644 --- a/drivers/gpu/drm/radeon/radeon_i2c.c +++ b/drivers/gpu/drm/radeon/radeon_i2c.c @@ -53,8 +53,8 @@ bool radeon_ddc_probe(struct radeon_connector *radeon_connector) }; /* on hw with routers, select right port */ - if (radeon_connector->router.valid) - radeon_router_select_port(radeon_connector); + if (radeon_connector->router.ddc_valid) + radeon_router_select_ddc_port(radeon_connector); ret = i2c_transfer(&radeon_connector->ddc_bus->adapter, msgs, 2); if (ret == 2) @@ -1084,26 +1084,51 @@ void radeon_i2c_put_byte(struct radeon_i2c_chan *i2c_bus, addr, val); } -/* router switching */ -void radeon_router_select_port(struct radeon_connector *radeon_connector) +/* ddc router switching */ +void radeon_router_select_ddc_port(struct radeon_connector *radeon_connector) { u8 val; - if (!radeon_connector->router.valid) + if (!radeon_connector->router.ddc_valid) return; radeon_i2c_get_byte(radeon_connector->router_bus, radeon_connector->router.i2c_addr, 0x3, &val); - val &= radeon_connector->router.mux_control_pin; + val &= radeon_connector->router.ddc_mux_control_pin; radeon_i2c_put_byte(radeon_connector->router_bus, radeon_connector->router.i2c_addr, 0x3, val); radeon_i2c_get_byte(radeon_connector->router_bus, radeon_connector->router.i2c_addr, 0x1, &val); - val &= radeon_connector->router.mux_control_pin; - val |= radeon_connector->router.mux_state; + val &= radeon_connector->router.ddc_mux_control_pin; + val |= radeon_connector->router.ddc_mux_state; + radeon_i2c_put_byte(radeon_connector->router_bus, + radeon_connector->router.i2c_addr, + 0x1, val); +} + +/* clock/data router switching */ +void radeon_router_select_cd_port(struct radeon_connector *radeon_connector) +{ + u8 val; + + if (!radeon_connector->router.cd_valid) + return; + + radeon_i2c_get_byte(radeon_connector->router_bus, + radeon_connector->router.i2c_addr, + 0x3, &val); + val &= radeon_connector->router.cd_mux_control_pin; + radeon_i2c_put_byte(radeon_connector->router_bus, + radeon_connector->router.i2c_addr, + 0x3, val); + radeon_i2c_get_byte(radeon_connector->router_bus, + radeon_connector->router.i2c_addr, + 0x1, &val); + val &= radeon_connector->router.cd_mux_control_pin; + val |= radeon_connector->router.cd_mux_state; radeon_i2c_put_byte(radeon_connector->router_bus, radeon_connector->router.i2c_addr, 0x1, val); diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h index feaa5e7..51e2126 100644 --- a/drivers/gpu/drm/radeon/radeon_mode.h +++ b/drivers/gpu/drm/radeon/radeon_mode.h @@ -403,13 +403,19 @@ struct radeon_hpd { }; struct radeon_router { - bool valid; u32 router_id; struct radeon_i2c_bus_rec i2c_info; u8 i2c_addr; - u8 mux_type; - u8 mux_control_pin; - u8 mux_state; + /* i2c mux */ + bool ddc_valid; + u8 ddc_mux_type; + u8 ddc_mux_control_pin; + u8 ddc_mux_state; + /* clock/data mux */ + bool cd_valid; + u8 cd_mux_type; + u8 cd_mux_control_pin; + u8 cd_mux_state; }; struct radeon_connector { @@ -490,7 +496,8 @@ extern void radeon_i2c_put_byte(struct radeon_i2c_chan *i2c, u8 slave_addr, u8 addr, u8 val); -extern void radeon_router_select_port(struct radeon_connector *radeon_connector); +extern void radeon_router_select_ddc_port(struct radeon_connector *radeon_connector); +extern void radeon_router_select_cd_port(struct radeon_connector *radeon_connector); extern bool radeon_ddc_probe(struct radeon_connector *radeon_connector); extern int radeon_ddc_get_modes(struct radeon_connector *radeon_connector); -- 1.7.1.1

1 1

[PATCH] gpu: drm: vmwgfx: fix information leak to userland
by Vasiliy Kulikov 08 Nov '10

08 Nov '10

Structure drm_vmw_fence_rep is copied to userland with field "pad64" uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov <segooon(a)gmail.com> --- Compile tested. drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c index 51d9f9f..76954e3 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -691,6 +691,7 @@ int vmw_execbuf_ioctl(struct drm_device *dev, void *data, fence_rep.error = ret; fence_rep.fence_seq = (uint64_t) sequence; + fence_rep.pad64 = 0; user_fence_rep = (struct drm_vmw_fence_rep __user *) (unsigned long)arg->fence_rep; -- 1.7.0.4

2 1

[PATCH] drm: idr_find (drm_gem_object_lookup) needs only rcu read locks
by Chris Wilson 08 Nov '10

08 Nov '10

... other mutation of the handle idr is still serialised using spin locks. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> --- drivers/gpu/drm/drm_gem.c | 20 ++++++++------------ 1 files changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ea1c4b0..ce63a14 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -184,7 +184,6 @@ EXPORT_SYMBOL(drm_gem_object_alloc); static int drm_gem_handle_delete(struct drm_file *filp, u32 handle) { - struct drm_device *dev; struct drm_gem_object *obj; /* This is gross. The idr system doesn't let us try a delete and @@ -204,12 +203,13 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) spin_unlock(&filp->table_lock); return -EINVAL; } - dev = obj->dev; /* Release reference and decrement refcount. */ idr_remove(&filp->object_idr, handle); spin_unlock(&filp->table_lock); + synchronize_rcu(); + drm_gem_object_handle_unreference_unlocked(obj); return 0; @@ -257,18 +257,14 @@ drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp, { struct drm_gem_object *obj; - spin_lock(&filp->table_lock); + rcu_read_lock(); /* Check if we currently have a reference on the object */ obj = idr_find(&filp->object_idr, handle); - if (obj == NULL) { - spin_unlock(&filp->table_lock); - return NULL; - } - - drm_gem_object_reference(obj); + if (obj) + drm_gem_object_reference(obj); - spin_unlock(&filp->table_lock); + rcu_read_unlock(); return obj; } @@ -363,11 +359,11 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data, if (!(dev->driver->driver_features & DRIVER_GEM)) return -ENODEV; - spin_lock(&dev->object_name_lock); + rcu_read_lock(); obj = idr_find(&dev->object_name_idr, (int) args->name); if (obj) drm_gem_object_reference(obj); - spin_unlock(&dev->object_name_lock); + rcu_read_unlock(); if (!obj) return -ENOENT; -- 1.7.2.3

1 1

INFO: possible circular locking dependency detected [v2.6.37-rc1-152-g6c88078]
by Uwe Helm 08 Nov '10

08 Nov '10

Hi, I've been seeing these lately, Xorg version is 1.9.0 with latest git kernel. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.37-rc1-uwe1+ #4 ------------------------------------------------------- Xorg/1401 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<c01e4ddb>] might_fault+0x4b/0xa0 but task is already holding lock: (&dev->struct_mutex){+.+.+.}, at: [<f869c3ac>] i915_mutex_lock_interruptible+0x3c/0x60 [i915] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&dev->struct_mutex){+.+.+.}: [<c01738ec>] lock_acquire+0x7c/0x120 [<c04d3560>] mutex_lock_nested+0x60/0x330 [<f810c7aa>] drm_gem_mmap+0x3a/0x140 [drm] [<c01ec202>] mmap_region+0x2e2/0x430 [<c01ec59f>] do_mmap_pgoff+0x24f/0x2f0 [<c01ec6bb>] sys_mmap_pgoff+0x7b/0x110 [<c0102f97>] sysenter_do_call+0x12/0x36 -> #0 (&mm->mmap_sem){++++++}: [<c0173549>] __lock_acquire+0x14a9/0x17d0 [<c01738ec>] lock_acquire+0x7c/0x120 [<c01e4e0c>] might_fault+0x7c/0xa0 [<c032dfad>] _copy_from_user+0x3d/0x130 [<f869cdec>] i915_gem_pwrite_ioctl+0x18c/0xb20 [i915] [<f810afd2>] drm_ioctl+0x1e2/0x440 [drm] [<c0216dcd>] do_vfs_ioctl+0x9d/0x6c0 [<c0217457>] sys_ioctl+0x67/0x80 [<c0102f97>] sysenter_do_call+0x12/0x36 other info that might help us debug this: 1 lock held by Xorg/1401: #0: (&dev->struct_mutex){+.+.+.}, at: [<f869c3ac>] i915_mutex_lock_interruptible+0x3c/0x60 [i915] stack backtrace: Pid: 1401, comm: Xorg Not tainted 2.6.37-rc1-uwe1+ #4 Call Trace: [<c04d12de>] ? printk+0x1d/0x1f [<c01714f2>] print_circular_bug+0xc2/0xd0 [<c0173549>] __lock_acquire+0x14a9/0x17d0 [<c04d82c9>] ? sub_preempt_count+0x9/0x50 [<c01738ec>] lock_acquire+0x7c/0x120 [<c01e4ddb>] ? might_fault+0x4b/0xa0 [<c01e4e0c>] might_fault+0x7c/0xa0 [<c01e4ddb>] ? might_fault+0x4b/0xa0 [<c032dfad>] _copy_from_user+0x3d/0x130 [<f869cdec>] i915_gem_pwrite_ioctl+0x18c/0xb20 [i915] [<c01e4ddb>] ? might_fault+0x4b/0xa0 [<f810afd2>] drm_ioctl+0x1e2/0x440 [drm] [<f869cc60>] ? i915_gem_pwrite_ioctl+0x0/0xb20 [i915] [<c02f36d3>] ? smk_access+0xb3/0x1f0 [<c02f3914>] ? smk_curacc+0x74/0xa0 [<f810adf0>] ? drm_ioctl+0x0/0x440 [drm] [<c0216dcd>] do_vfs_ioctl+0x9d/0x6c0 [<c0217457>] sys_ioctl+0x67/0x80 [<c0102f97>] sysenter_do_call+0x12/0x36 thanks, Uwe

1 0

[Bug 702] Radeon only supports a maximum point size of 1.0.
by bugzilla-daemon＠freedesktop.org 06 Nov '10

06 Nov '10

https://bugs.freedesktop.org/show_bug.cgi?id=702 --- Comment #12 from Daniel Richard G. <skunk(a)iskunk.org> 2010-11-06 11:17:39 PDT --- > I think either this should be commited or instead it should be handled > by the driver and the DD_POINT_SIZE flag completely removed as it's > currently just broken. Since the plan initially was to remove the > whole _TriangleCaps stuff and r200 is the only driver which makes use > of this particular flag I'm leaning towards the latter. Sounds like a good way to go. Fewer idiosyncrasies in older drivers should be a win. > In fact, the driver is quite broken anyway wrt point size, since with > vertex programs you could output the point size per vertex, but the > driver might still use the 1-sized point primitive, since > _TriangleCaps DD_POINT_SIZE only looks at the global point size. Still a better bug to have, at least, since vertex programs are a newer construct anyway (and less likely to be used in CAD-type scenarios). > But I really have no idea why the driver tries to use the point > primitive instead of point sprite for 1-pixel points, otherwise it > would be easiest to just always use point sprite prim (at least for aa > points) which would get rid of both bugs. FWIW, I modified the "point" demo into a poor man's benchmark (by putting the glBegin(GL_POINTS) and glVertex*() calls inside large loops, and adding gettimeofday() calls), and I'm seeing basically no differences between 1.0 and 1.001 for glPointSize(). You'd think the 1-pixel-point primitives would be faster on some hardware, but r200 doesn't seem to special-case those. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 702] Radeon only supports a maximum point size of 1.0.
by bugzilla-daemon＠freedesktop.org 06 Nov '10

06 Nov '10

https://bugs.freedesktop.org/show_bug.cgi?id=702 Roland Scheidegger <sroland(a)vmware.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brianp(a)vmware.com --- Comment #11 from Roland Scheidegger <sroland(a)vmware.com> 2010-11-06 07:05:57 PDT --- (In reply to comment #10) > Your patch applies cleanly to 7.7.1, and indeed, it makes the points big! The > modified "point" demo, "pointblast" (only w/"Point smooth off"), and Wings3D > all now do as they should. Should I test your patch with bleeding-edge code? That should still work the same. > > I don't know what to make of the patch tweaking generic code instead of driver > code, but it surely solves the problem for me. Could this, or some form of > this, be committed into the tree? I think either this should be commited or instead it should be handled by the driver and the DD_POINT_SIZE flag completely removed as it's currently just broken. Since the plan initially was to remove the whole _TriangleCaps stuff and r200 is the only driver which makes use of this particular flag I'm leaning towards the latter. In fact, the driver is quite broken anyway wrt point size, since with vertex programs you could output the point size per vertex, but the driver might still use the 1-sized point primitive, since _TriangleCaps DD_POINT_SIZE only looks at the global point size. But I really have no idea why the driver tries to use the point primitive instead of point sprite for 1-pixel points, otherwise it would be easiest to just always use point sprite prim (at least for aa points) which would get rid of both bugs. (The other DD_POINT flags are also problematic - well DD_POINT_SMOOTH is not but that one just directly mirrors ctx->Point.Smooth. But DD_POINT_ATTEN is also meaningless with vertex programs. i915 uses this and at a quick glance I don't think it gets it right neither.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 702] Radeon only supports a maximum point size of 1.0.
by bugzilla-daemon＠freedesktop.org 06 Nov '10

06 Nov '10

https://bugs.freedesktop.org/show_bug.cgi?id=702 --- Comment #10 from Daniel Richard G. <skunk(a)iskunk.org> 2010-11-06 00:01:19 PDT --- Hi Roland, I see you've been here before! I no longer have the Ubuntu Maverick install I was testing with earlier (I don't have the disk it was on anymore), but I do have here an Ubuntu Lucid install (same hardware) with Mesa 7.7.1, which gives me this: $ glxinfo -l | grep -i point GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_ALIASED_POINT_SIZE_RANGE = 1, 2047 GL_SMOOTH_POINT_SIZE_RANGE = 1, 1 That seems to agree with what you said. Your patch applies cleanly to 7.7.1, and indeed, it makes the points big! The modified "point" demo, "pointblast" (only w/"Point smooth off"), and Wings3D all now do as they should. Should I test your patch with bleeding-edge code? I don't know what to make of the patch tweaking generic code instead of driver code, but it surely solves the problem for me. Could this, or some form of this, be committed into the tree? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 702] Radeon only supports a maximum point size of 1.0.
by bugzilla-daemon＠freedesktop.org 06 Nov '10

06 Nov '10

https://bugs.freedesktop.org/show_bug.cgi?id=702 --- Comment #9 from Roland Scheidegger <sroland(a)vmware.com> 2010-11-05 21:54:43 PDT --- Created an attachment (id=40078) View: https://bugs.freedesktop.org/attachment.cgi?id=40078 Review: https://bugs.freedesktop.org/review?bug=702&attachment=40078 trivial possible fix Here's a simple patch which would restore previous (2006...) behaviour... Though I'm thinking probably the driver should just do this on its own depending on the ctx->Point.Size. Note the problem is the hardware has two hw primitives for points: point sprite and point. Only the former can have size larger than 1. I'm not quite sure (or can't remember) why we're not always using point sprites but points when the size is 1 and it's not attenuated. Maybe it's faster. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 702] Radeon only supports a maximum point size of 1.0.
by bugzilla-daemon＠freedesktop.org 06 Nov '10

06 Nov '10

https://bugs.freedesktop.org/show_bug.cgi?id=702 --- Comment #8 from Roland Scheidegger <sroland(a)vmware.com> 2010-11-05 21:38:01 PDT --- Hmm actually I see the problem. The driver relies on ctx->_TriangleCaps and tests for DD_POINT_SIZE. But nothing ever sets this - update_tricaps would but it's ifdefed out as it was basically reverted, looks like the revert wasn't quite complete. Note that it should still work if point attenuation is used (e.g. pointblast demo). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 702] Radeon only supports a maximum point size of 1.0.
by bugzilla-daemon＠freedesktop.org 06 Nov '10

06 Nov '10

https://bugs.freedesktop.org/show_bug.cgi?id=702 --- Comment #7 from Roland Scheidegger <sroland(a)vmware.com> 2010-11-05 21:10:13 PDT --- (In reply to comment #6) > This bug still exists on r200, and possibly Radeon generally. I am quite sure this used to work on r200 (not r100 which can't do it natively). Aliased points should be supported up to size 2047 (though antialiased points are still limited to size 1). What does glxinfo -l say wrt point size? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2010