pbuffers

Brian Paul brian@tungstengraphics.com
Sat, 06 Dec 2003 10:46:26 -0700


Keith Whitwell wrote:
> Brian Paul wrote:
> 
>> Jon Smirl wrote:
>>
>>> It's going to take Brian, Keithw and myself another month or two to 
>>> get a full
>>> standalone OpenGL running. We are missing two major pieces of code, 
>>> pbuffers and
>>> mode support.
>>
>>
>>
>> I started looking at what it would take to get pbuffers going with 
>> mesa-solo, in the r200 driver.  It looks like it'll be some work.
>>
>> For rendering to off-screen color/depth/stencil buffers we need to 
>> pass the buffer's start and stride to the kernel module.  Luckily, it 
>> looks like that's transferred in the drm_radeon_context_regs_t 
>> structure, and not fixed at initialization time.
>>
>> However, this info seems to be ignored in the 
>> radeon_cp_dispatch_clear() function; it seems to assume you're always 
>> clearing the front/back color and depth/stencil buffers.
>>
>> A work-around would be to draw a filled polygon to implement the 
>> clear, but I'm wondering where else there might be similar assumptions 
>> to trip us up.
> 
> 
> Why not just fix the ioctl?

I'm not going to touch it until I understand things better.

It seems that we'd need the drm_radeon_context_regs_t *ctx pointer in 
that function, but I'm not sure how to get it.

Then, drm_radeon_context_regs_t *ctx doesn't have the offset/pitch 
info for both the front and back color buffers.  So doing simultaneous 
front/back clears might not work anymore.

Looks like we're drawing a filled quad to do depth/stencil clears on 
the r200 anyway.


>> The other thing we need is a mechanism to allocate the memory for 
>> pbuffers.  My first guess is that this would have to be allocated out 
>> of the space used for textures.  I think the DRI texture memory 
>> allocator could be adapted to do this.
> 
> 
> Correct.  There's a memory manager there for AGP space, but it's not 
> integrated with the texture manager.  In the i830 driver, particularly 
> the one on the agp-i865-0-1-branch, I have a kernel memory manager which 
> integrates fairly smoothly with the client-driver's texture memory 
> manager.  This is probably a decent starting point.

OK.

-Brian